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(S) Apparatus and methods for implementing protocols. 

(57) Apparatus and methods for communicating using protocols. The apparatus and methods employ 
protocol descriptions written in a device-independent protocol description language. A protocol is 
executed by employing a protocol description language interpreter to interpret the protocol descrip- 
tion. Communication using any protocol for which there is a protocol description may be done by 
means of a general protocol. The general protocol includes a first general protocol message which 
includes a protocol description for a specific protocol. The protocol apparatus which receives the first 
protocol message employs a protocol description language interpreter to interpret the included 
protocol description and thereby to execute the specific protocol. The protocol apparatus may also be 
made to adapt to its environment by encaching protocol descriptions which were received in an earlier 
first general protocol message and interpreting an encached protocol description in response to a 
second general protocol message which includes a protocol identifier specifying the encached protocol 
description. 
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means capable of interpreting the protocol description language to interpret the protocol description as 

required to communicate using the specific protocol. 
In still another aspect the invention is protocol apparatus for communicating in distributed system, the appa- 
ratus including: 

5 . means for receiving a first general protocol message, the first general protocol message including a pro- 

tocol description which describes a specific protocol and which employs a protocol description language 
which is independent of any particular implementation of the protocol apparatus; and 
. means for responding to the first general protocol message which are capable of interpreting the protocol 
description language and which interpret the protocol description as required to communicate using the 
io specific protocol. 

In a further aspect, the invention is apparatus for communicating in a distributed system, the apparatus includ- 
ing: 

. first protocol apparatus for communicating using a general protocol and 
. second protocol apparatus for communicating using the general protocol, 
is . the first protocol apparatus including 

. means for providing a first general protocol message which includes a protocol description which de- 
scribes a specific protocol and which employs a protocol description language which is independent of 
any particular implementation of the second protocol apparatus; and 
. means for employing the specific protocol to communicate with the second protocol apparatus after pro- 
20 viding the first general protocol message; and 

. the second protocol apparatus including 

means for receiving the first general protocol message from the first protocol apparatus; and 
. means for responding to the first general protocol message which are capable of interpreting the protocol 
description language and which interpret the protocol description as required to communicate using the 
25 specific protocol. 

The foregoing and other aspects, objects and advantages of the invention will be apparent to one of ordinary 
skill in the art who peruses the following Drawing and Detailed Description, wherein: 

Brief Description of the Drawing 

30 

FIG. 1 is a block diagram of a typical system in which protocols are used; 
FIG. 2 is a block diagram of a first apparatus incorporating the invention; 
FIG. 3 is a block diagram of a second apparatus incorporating the invention; 
FIG. 4 is a table of instructions in a protocol description language; 
35 FIG. 5 is a flowchart of the bootstrap state; 

FIG. 6 is a flowchart of the error state; 
FIG. 7 is a state diagram for the alternating bit protocol; 

FIG. 8 is a protocol description for the receive side of the alternating bit protocol; 
FIG. 9 is a protocol description for the send side of the alternating bit protocol; 
40 FIG. 10 is a fragment of the transition procedure; 

FIG. 11 is a protocol description for the bootstrap state; 
FIG. 12 is a protocol description for the error state; and 

FIG. 13 is a block diagram of an embodiment which encaches downloaded protocol descriptions. 
The reference numbers employed in the Drawing and the Detailed Description have three or more digits. 
45 The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, 
the element with the reference number "305" is first shown in FIG. 3. 

Detailed Description 

so The following Detailed Description will first provide an overview of the techniques of the invention and will 

then disclose in detail how the Alternating Bit Protocol (described at Holzmann, supra, pp. 75-77) may be im- 
plemented using the techniques of the invention. 

Overview: FIGs. 1*3 

55 

FIG. 1 is a block diagram of a system 101 in which protocols are used for communication between a first entity 
109(1) and a second entity 109(2). Each entity 109 includes a source or destination 103 for information (INFO) 
105 and a protocol apparatus 107. 

3 
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mentations of protocol apparatus 201 will implement different versions of the protocol. Second, protocol de- 
scription 203 is written only once, but will be used many times. It is therefore worthwhile to expend great efforts 
to ensure that protocol description 203 is in fact a correct, complete and unambiguous description of the pro- 
tocol. Third, the part of protocol apparatus 201 which may differ in the different implementations is protocol 

5 execution device 207. However, protocol execution device 207 must now only be able to correctly execute the 
protocol instructions 205 in protocol description 203. That is, the problem is no longer the correct implemen- 
tation of the protocol, but rather the correct implementation of an instruction set in a single device. This problem 
is, however, far better understood than the problem of implementing a protocol in two devices, and consequent- 
ly, implementations of the protocol instruction set in different protocol apparatuses 201 are far more likely to 

10 be correct than implementations of the protocol itself. 

Apparatus for Executing a General Protocol: FIGs. 3 and 13 

Perhaps the most significant advantage of protocol apparatus 201 is that it can execute any protocol for 
is which there is a protocol description 203 written in the protocol description language. Consequently, protocol 
apparatus 201 can easily be modified to make a general protocol apparatus which executes a general protocol 
and which can therefore dynamically execute any protocol for which there is a protocol description 203. The 
general protocol is simply the following: 

. in a sending protocol apparatus, sending a general protocol message which includes a protocol descrip- 
20 tion 203; 

. in a receiving general protocol apparatus, employing protocol instruction interpreter 209 to execute the 

protocol description 203 contained in the general protocol message. 
FIG. 3 shows such a general protocol apparatus 301. General protocol apparatus 301 includes protocol 
instruction interpreter memory (PIIM) 309, which contains protocol description 203 for the protocol currently 

25 being executed by protocol apparatus 301 and protocol instruction interpreter data (PIIDATA) 311 , which is data 
employed by protocol instruction interpreter 209 in executing protocol description 203. Protocol interpreter 209 
has two additional components: bootstrap component (BOOT) 305 and error component (ERR) 307. These 
components make it possible for general protocol apparatus 301 to execute the general protocol, and thereby 
make it possible for any protocol apparatus 107 which can provide a protocol description 203 to protocol ap- 

30 paratus 301 to use the protocol described in the protocol description 203 to communicate between the entities 
109 to which protocol apparatus 107 and protocol apparatus 301 belong. Of course, both protocol apparatuses 
involved in the communication may be general protocol apparatuses 301. 

Protocol apparatus 301 executes the general protocol as follows: bootstrap 305 listens for a general pro- 
tocol message (indicated by arrow 313) from the other protocol apparatus. In a preferred embodiment, the 

35 general protocol message uses the same path between the protocol apparatuses as does protocol data 111. 
In other embodiments, there may be a special path for the general protocol message. The general protocol 
message further contains at least the first part of protocol description 203 for the specific protocol to be exe- 
cuted. When bootstrap 305 receives the general protocol message, it loads the message into a buffer in pro- 
tocol instruction interpreter data 311 and performs checks as described below. If the message passes the 

40 checks, bootstrap 305 loads the general protocol message into the portion of memory 309 reserved for protocol 
description 203. Thereupon, interpreter 209 begins executing the protocol instructions 205 in the message, 
beginning with the initial instruction. If protocol description 203 is longer than the maximum size of an general 
protocol message, then the first part of protocol description 203 contains protocol instructions which, when 
executed, cause the rest of protocol description 203 to be loaded. 

45 In a preferred embodiment, the general protocol requires that the general protocol message contain check- 

ing information which permits error checking and protocol data information which indicates how protocol in- 
struction interpreter 209 is to interpret protocol data 111 and that the receiving general protocol apparatus 301 
use the checking information and the protocol data information. In the preferred embodiment, there are two 
items of checking information; a checksum for the general protocol message and a required first instruction. 

so On receiving the general protocol message, bootstrap 305 computes the general protocol message's check- 
sum and compares it with the checksum in the message; if they are different, there has been a transmission 
error and bootstrap 305 waits for another general protocol message. If bootstrap 305's check of the required 
first instruction in the general protocol message indicates that the general protocol message is not a protocol 
description 203, the error component 307 of protocol instruction interpreter 209 returns an error message (in- 

55 dicated by arrow 31 5) to the protocol apparatus 101 which provided the general protocol message. Thereupon, 
error 307 waits for a valid general protocol message. O nee the general protocol message has been successfully 
received, it is executed by protocol instruction interpreter 209, and as part of the execution, the protocol data 
information in the general protocol message is used to set parameter values in protocol instruction interpreter 
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scription. 

As will be explained in more detail below, the protocol descriptions 203 employed in a preferred embodi- 
ment define a finite state machine. Consequently, a given protocol description 203 is divided into a set of num- 
bered states (S)1321. To permit location of the states, protocol description 1311 is divided into two parts: pro- 

5 tocol description body (PDB) 1314, which contains the instructions for the states, and state table 1313, which 
relates state numbers to the locations of the corresponding states 1321. There is an entry 1315 in state table 
1313 for each state 1321 in the protocol description body, and each entry contains the state number (SN) 1317 
and the offset (OFF) 1319 of that state from the beginning of protocol description 1311. 

The modifications required in bootstrap 305 will be immediately apparent from FIG. 13 and the description 

to of the general protocol for general protocol apparatus 1323. When a general protocol message is received 
which contains a protocol description identifier for which the protocol description! 311 is in memory 1302. boot- 
strap 305 simply causes interpreter 209 to begin executing the specified protocol description; otherwise, boot- 
strap 305 retains the identifier from the general protocol message and causes error 307 to return an error mes- 
sage and wait for a message which contains the protocol description 1311. When the message arrives, error 

15 307 causes bootstrap 305 to compare the retained identifier with the identifer in the general protocol message 
containing the protocol description 1311, and if they agree, bootstrap 305 places the protocol description 1311 
in memory 1302 and makes an entry 1305 for the new protocol description 1311 in protocol description table 
1303. 

Of course, many variation on the above arrangements are possible. For example, memory 1302 is nec- 
20 essarily finite; consequently, bootstrap 305 may have to remove one protocol description 1311 to make room 
for another. One way of doing this would be to include size and most recent use information in protocol de- 
scription table 1303, and bootstrap 305 could use that information to determine which protocol descriptions 
1311 should be removed. Further, the general protocol for general protocol apparatus 1323 might include a 
checksum in the general protocol message for the protocol description 1311 identified by the identifier. Boot- 
25 strap 305 could use the checksum to make sure that the copy of the protocol description 1311 in memory 1302 
was the same as the copy held by the sender. If it was not, bootstrap 305 could send an error message re- 
questing the protocol description and then proceed as previously described for protocol descriptions for which 
there was no copy in memory 1302. 

30 Implementation of Protocol Apparatus 301 

A prototype implementation of protocol apparatus 301 has been constructed in which protocol execution 
device 207 is a computer capable of executing programs written in the well-known M C H programming language. 
In the prototype implementation, protocol instructions 205 belonging to a protocol description language are 

35 interpreted by a protocol instruction interpreter which is written in C and is executed by a process running on 
the computer. General protocol apparatus 301 has been tested by writing a protocol description 203 for the 
alternating bit protocol in the protocol description language and executing the protocol by executing the pro- 
tocol description 203. The following discussion will first disclose the protocol description language, then pro- 
tocol interpreter 209, bootstrap 305, and error component 307, and finally protocol description 203 for the al- 

40 ternating bit protocol. 

The Protocol Description Language: FIG.4 

FIG. 4 shows the instructions in a preferred embodiment of protocol description language 401 . The instruc- 
ts tions fall into two classes: those which perform general stack management and expression evaluation, shown 
in table 403, and those which perform operations which are particularly related to the execution of protocols, 
shown in table 405. 

As is apparent from table 403, protocol instruction interpreter 209 is a stack machine. The stack, maintained 
in protocol instruction interpretation data 311, is a standard integer size push-down stack. The PUSH_BYTE 

50 and PUSH_WORD instructions permit data to be pushed onto the push-down stack. The other instructions 
take their operands and parameters from the top of the stack and push their results back onto the top of the 
stack. When a stack overflow or underflow occurs, interpreter 209 ceases executing the protocol, error com- 
ponent 307 sends an error message to the other protocol apparatus 107, and error component 307 then waits 
for an error handling message from the other protocol apparatus 107. Of course, how the other protocol ap- 

55 paratus 107 responds to the error message is part of the protocol described in protocol description 203. The 
same thing happens if an arithmetic error such as a zero divide or an integer overflow occurs. 

The functions of the instructions in table 405 are generally clear from the table; however, certain instruc- 
tions require a more detailed explanation. Beginning with the instructions in finite state machine control 407, 
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The body of the while loop is a switch statement incremented by 1 , so that it 

toco, description language 401. On each ^^.^^J^i, case is executed. If there is no 
points to the next byte in the state. The value 0 f ha ^^STIteh i» interpreter 209 into the error state 
case corresponding to that value. 5 » a case further contains debugging code and as- 

and thereby transfers control to ^^Te^ononZ instruction are fulfilled, .f interpreter 209 is 
^^^^^^^Zns 203. the asserts and debugging code may be 

^ment ,00, shows two cases in ~ «~ ^^X^" 
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Implementation of Boo tstrap 305-.FIG.5 
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protocol description 203. ,^^ onte H uuith a sinale call run (BOOTSTRAP). Procedure 

pletely below. 
run(S) 

{ int n = s; 

while (n >= 0 && n <= SMAX && State[n].cont) 

n = transition(n); 
return n; 
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o is non-zero, a transmission error has < ^^^^^ nMaaQ0 has the correcttype (diamond 509). 
amond 505. 507). If the checksum is zero, a check is made « tne m « BYTEORDER for the lower 

,n a preferred embodiment, the first instruction ,,s required to be the def m,t on of the^ ^ ^ ^ 
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at byte 18 is reserved for the checksum which bootstrap 305 uses to check for correctness of transmission. 

Portion 807 is state 1 of the portion of the finite state machine which receives messages. In th.s state, 
the finite state machine waits for a message (byte 0). When the message arrives, it is placed in RBUF. At bytes 
2 through 12 the finite state machine writes a value indicating an acknowledgment (in this case, the charac- 
ter TV) into the transmittal buffer, obtains the sequence number in the last byte of RBUF. cop.es the sequence 
number into TBUF following the 'A', and sends the acknowledgment. At bytes 14 through 20, the finite state 
machine compares the value of the sequence number retained in VAR_E with the sequence number ,n the 
last byte of RBUF If they are the same, indicating that the received message had the right sequence number, 
bytes 23 through 33 are executed; otherwise, state 1 is again executed from the beginning, as shown at byte 
34 In bytes 23 through 31. the sequence number saved in VAR_E is subtracted from 1 and the result saved 
in VAR_E again. Then, the message is sent to its destination and state 1 is again executed from the beginning. 

FIG 9 shows how the portion of the alternating bit protocol which sends messages is implemented in a 
preferred embodiment. In the preferred embodiment, protocol apparatus 107 in which send portion 901 is im- 
plemented is a protocol apparatus 201 or 301 which is sending to a protocol apparatus 301. Consequently, the 
send portion is implemented in protocol description language 401 and includes instructions which download 
receive portion 801 to the receiving protocol apparatus 301. 

The buffers and variables used in portion 901 are defined in part 803 of FIG. 8. In the prototype, buffers 
0 and 1 are preset to each contain a message; as may be seen from part 809 of FIG. 8. buffer 0 (named M0) 
is set to the ASCII character "M' with the sequence number "0" appended to it. while buffer 1 is set to the ASCII 
character 'M' with the sequence number "1" appended to it. The buffer R_run contains the code of port.on 807. 
while the buffer R_ini contains the code of portion 805. The buffer R_ack. finally, is used for the acknowledge- 
ment received from receiver 801. There are two variables: VAR_S. which holds the sequence number which 
is to be attached to the message, and VAR.CNT. which is a count of the number of bytes sent by the sender. 

Returning to FIG. 9, the allocation and initialization of the sender buffers and variables defined in 803 takes 
place in section 903, which is state 0. In bytes 0-13, VAR_S and VAR_CNT are both allocated and set to 0; in 
bytes 14 and 15. receiver initialization code 805. contained in the buffer R_ini. is sent to the receiver; in bytes 
16 and 17 the code 807 for state 1 of the receiver, contained in the buffer R_run. is sent to the receiver. These 
lines 905 thus perform the downloading bf protocol description 203 to the receiving protocol apparatus 301. 
At byte 18, finally, the l_NXT instruction starts execution of state 1 907. 

At bytes 0-2 of state 1 907. the current value of VAR_S is pushed onto the stack. At byte 3. SEND takes 
its parameter from the top of the stack; thus, if VAR_S has the value 0. the message in buffer M0 is sent; if it 
has the value 1 the message in buffer M1 is sent. In an embodiment for use in an actual communications sys- 
tem there would be code preceding the SEND instruction which employed the OBTAIN instruction to obtain 
a byte of data to be sent and place the data in buffer M0 or M1 . depending on the value of VAR_S. and then 
employed CPY_BYTE to append "0" or "I" to the data, again depending on the value of VAR_S. 

The code in bytes 4-8 receives the acknowledgment from the receiver and pushes it onto the stack. As 
pointed out in the discussion of the receiver, the acknowledgment has the form •A , <sequence_number>. The 
top byte of the stack consequently should contain 'A' and the next byte should contain the sequence number. 
In bytes 9-11 the top byte is checked to see whether it contains 'A'. If it does, bytes 14-31 are executed; other- 
wise execution continues at byte 32. Bytes 14-31 check whether the acknowledgement has the right sequence 
number if it does, they set VAR_S to the next sequence number. More specifically, bytes 1 4-20 check whether 
the sequence number in the acknowledgment is the same as the value of VAR_S. If it is not. execution con- 
tinues at byte 32; if it is, VAR_S is set to its new value by subtracting its current value from 1 (bytes 23-31). 

The code in bytes 32-54 updates VAR.CNT and terminates state 1 if the number of messages is greater 
than the constant NR.MSGS. defined in 8~03 to be 32765. In bytes 32-40, 1 is added to the current : value * of 
VAR CNT In bytes 41-47, VAR_CNT is pushed onto the stack, the most and least significant bytes of NR.MSGS 
is pushed onto the stack, and the two values are compared. If VAR_CNT>=NR_MSGS, bytes 50-52 put the 
value -1 on the stack. NXT returns that value to run, which thereupon terminates, as previously explained. 
Otherwise, byte 54 is executed, which causes state 1 907 to again begin execution. 

Performance of Protocol Apparatus 201 or 301 

The performance of the implementation of the alternating-bit protocol just described was compared with 
the performance of an implementation in which the sender and receiver were simply coded in the 'C' •program- 
ming language. The extra overhead caused by the use of protocol description 203 and interpreter 209 .nstead 
of a "C" program ranged from 10-30%, depending on the length of the message being transmitted (longer mes- 
sages have the lower overhead). In many applications, the extra overhead will be offset by the 'act that the 
protocol apparatus of the invention can interpret any protocol for which there is a protocol description 203. Fur- 
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apparatus; and , . . 

employing the specific protocol to communicate with the first protocol apparatus. 

7. The method set forth in claim 6 further characterized by: 

in the first entity. . 
receiving a second general protocol message which includes a protocol specifier specifying the 

protocoMescnp^on, ^ by determining whe therthe specified protocol 

description is accessible to the first entity; 

if the specified protocol description is accessible, employing the first protocol description interpre- 
tation means to interpret the specified protocol description; but 

if the specified protocol description is not accessible, sending a first error message and thereupon 
performing the step of receiving the first general protocol message. 

8. Protocol apparatus (301 ) for communicating in a distributed system, the apparatus being characterized 

means (305) for receiving a first general protocol message, the first general protocol message in- 
cluding a protocol description (203) which describes a specific protocol and which employs a protocol de- 
scription language which is independent of any particular implementation of the protocol apparatus; and 

means (209) for responding to the first general protocol message which are capable of interpreting 
the protocol description language and which interpret the protocol description as required to communicate 
using the specific protocol. 

9 The protocol apparatus set forth in claim 8 further characterized in that: 

the means for receiving further checks the first general protocol message. 

10 The protocol apparatus set forth in claim 8 further characterized in that: 

the first general protocol message includes a parameter (415) for interpreting protocol data trans- 
ferred according to the specif ic protocol; and a(W , r H 

the means for responding to the first general protocol message interprets the protocol data accord- 
ing to the parameter. 

11. The protocol apparatus set forth in claim 8 further characterized in that: 

the protocol apparatus further includes error handling means (307); 

the means for receiving the first general protocol message further receives a second general pro- 
tocol message including a protocol specifier (1307) specifying the protocol description, and 

the means for responding to the first general protocol message further responds to the second 
general protocol message by determining whether the specified protocol description is accessible and rf 
The specified protocol description is accessible, interpreting the specified protocol descnpt.on. but if the 
specified protocol description is not accessible, sending a first error message. 

12 Apparatus for Communicating in a distributed system, the apparatus being characterized by: 
first protocol apparatus (301) for communicating using a general protocol and 
second protocol apparatus (301) for communicating using the general protocol, 
the first protocol apparatus including 

means (209.903) for providing a first general protocol message which includes a protocol descrip- 
tion (203) which describes a specific protocol and which employs a protocol description language wh.ch 
is independent of any particular implementation of the second protocol apparatus; and 

means (209.907) for employing the specific protocol to communicate with the second protocol ap- 
paratus after providing the first general protocol message; and 

the second protocol apparatus including 

means (301 ) for receiving the first general protocol message from the first protocol apparatus; and 
means (209) for responding to the first general protocol message which are capable of interpreting 
the protocol description language and which interpret the protocol description as required to communicate 
using the specific protocol. 
13. Peripheral apparatus for communicating information using a protocol, the apparatus being characterized 
means (111) for transferring the information according to the protocol; 
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FIG. 8 
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BYTE Abp_rev_ini(] - { 
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in sam state •/ 


); - 
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BYTE MsgOf] - { /* message Buf (M0J, received in Buf [RBUF) */ 
'M', 0 

It- 
BYTE Msgl[] - ( /• message Buf [Ml] , received in Buf [RBUF ] •/ 
' M* , 1 

); 
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transitiorv(n) 

i BYTE bl, «cur_state - State in] .cent, 

static int StacMSMAX+1]; 
register BYTE *prot; 1005 
register int wO, wl, w2, i; 
register int -sp - iStack ISMAX] ; 

^1006 

prot - cur_state;^ ^ 009 

-while (prot) { , ' 

switch («prot++) < 
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/»«**• psM CONTROL 
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case NXT: 

assert (sp < iStacMSMAX] ) ; 

wO - POP; 

debugfnext %d0, wO, 0, 0, 0) ; 

if (wO < 0 II wO > SHXX II !State[wO] .cont) 

return ERRORSTXTE; 
return wO; 
case I_NXT: 

wO - *prot++; 

debug {-next %dO, wO, 0, 0, 0) ; 

if (wO < 0 II wO > SMXX II !StatelwO) .cor.-.) 

return ERRORSTXTE; 
return wO; 



f default 
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debugfError <%d>0, «prot, 0, 0, 0) ; 
return ERRORSTXTE; 
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(g) Apparatus and methods for implementing protocols. 

(57) Apparatus and methods for communicating 
^ using protocols. The apparatus and methods 
employ protocol descriptions wntten in a de- 
vice-independent protocol description lan- 
guage. A protocol is executed by employing a 
Protocol description language interpreter to in- 
terpret the protocol description. Communi- 
cation using any protocol for which there is a 
protocol description may be done by means of a 
general protocol. The general protocol inc udes 
a first general protocol message which includes 
a protocol description for a specific Protocol 
The protocol apparatus which receives the first 
protocol message employs a protocol descrip- 
tion language interpreter to interpret the in- 
cluded protocol description and thereby to 
execute the specific protocol. The protocol ap- 
paratus may also be made to adapt to its envi- 
ronment by encaching protocol descriptions 
which were received in an earlier first general 
protocol message and interpreting an encached 
CO protocol description in response to a second 
2 general protocol message which includes a 
protocol identifier specifying the encached pro- 
tocol description. 
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